Open
Conversation
PeerStore::add_peer previously returned early if a peer already existed, silently discarding address updates. When an LSP node's IP changed, the reconnection loop would indefinitely retry the stale cached address. This commit: 1. Changes add_peer to upsert: if the peer exists but the address differs, update and re-persist it. 2. Reorders Node::connect to persist the peer *before* attempting the connection, so the new address is saved even if the connection races with an in-flight reconnection attempt at the old address. 3. Adds unit tests for the upsert logic and an integration test for persist-on-failed-connect. See upstream issue lightningdevkit#700. Co-authored-by: Cursor <cursoragent@cursor.com>
Split wallet_sync_request into separate full_scan and incremental methods so only the needed request type is built. Introduce WalletSyncRequest enum to carry the chosen variant through the sync pipeline. Spawn primary and additional wallet syncs concurrently in a single JoinSet instead of running primary first. Batch update_payment_store_for_all_transactions and write_node_metrics into a single call after all updates are applied, and only when at least one update succeeded. Fix a pre-existing bug where additional wallet sync timestamps were set even when apply_update_for_address_type failed. Co-authored-by: Cursor <cursoragent@cursor.com>
…tched-payment-store refactor: lazy sync requests and batched payment store updates
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR:
PeerStore::add_peersilently ignoring address updates for already-known peers, causing the reconnection loop to use stale IPs indefinitely after an LSP node migrationNode::connectto persist the peer address before attempting the connection, so the updated address is saved even when the connection races with an in-flight reconnection attempt at the old addressWhen an LSP node's IP changes (e.g., LND4 moving from
34.65.186.40to34.65.153.174), nodes that previously connected would keep retrying the old cached address forever. The root cause was two-fold:add_peerreturned early for known peers without checking the address, andconnectonly persisted after a successful connection — meaning a racing reconnection loop could prevent the new address from ever being saved.This is the same fix as #53 (targeting
base/v0.7.0-rc.18) but rebased ontomain.See upstream issue #700.
QA Notes
Testing
cargo test --lib peer_store— runs the 3 unit tests (existing + 2 new:peer_address_updated_on_readd,peer_same_address_skips_persist)cargo test peer_address_persisted_on_connect_failure— integration test validating persist-before-connect and upsert across restart (requiresBITCOIND_EXE)cargo clippycleanIntegration
Made with Cursor